Summary

SimpleModule.Users 0.0.33 (and every other UI-shipping module) was published with an empty staticwebassets/ tree, so consumers got a 404 for /_content/SimpleModule.Users/SimpleModule.Users.pages.js and the login page rendered blank. Two independent root causes; this PR fixes both, and adds a CI smoke test so the next regression of this shape is caught at PR time.

Root causes

1. Release workflow never built the JS. publish-nuget ran npm ci then jumped straight to dotnet pack, with no npm run build in between. On a clean CI checkout each module's wwwroot/ was empty when pack ran, so the SDK had nothing to package.

2. Microsoft.NET.Sdk.StaticWebAssets evaluates Content Include="wwwroot/**" during MSBuild item evaluation, which runs before any target executes. Even with the existing JsBuild MSBuild target (BeforeTargets="Build"), the SDK had already locked in an empty file list by the time Vite ran. So dotnet pack invoked outside the workflow (or after a git clean) would still produce an empty package — the workflow fix alone wasn't enough.

Changes

1. npm run build before dotnet pack (release workflow)

Inserted between npm ci and dotnet restore in .github/workflows/release.yml so module wwwroot/ directories are populated before pack runs. Belt-and-suspenders alongside the MSBuild fix below; also a perf win because the orchestrator builds modules in parallel.

2. MSBuild: pre-populate @(Content) from built wwwroot/ (modules/Directory.Build.targets)

• Broadened JsBuild's BeforeTargets to also fire before ResolveStaticWebAssetsConfiguration, ResolveProjectStaticWebAssets, GetCopyToOutputDirectoryItems, and GenerateNuspec — covers dotnet pack invoked outside the Build chain.
• Added a ReincludeWwwrootContent target (AfterTargets="JsBuild" BeforeTargets="ResolveProjectStaticWebAssets") that re-adds wwwroot/** to @(Content) from inside MSBuild execution, after Vite has run. This is the actual fix for the cold-build case — without it, dotnet pack from a clean checkout still produces an empty staticwebassets/ tree even with the workflow fix.

3. CI smoke job (pack-smoke) + verification script

• New scripts/verify-nupkg-static-assets.mjs discovers UI-shipping modules (modules/*/src/*/ with a package.json next to a .csproj and a Pages/index.ts), then asserts each matching .nupkg contains:
  • staticwebassets/{Id}.pages.js (the SDK strips the wwwroot/ prefix when packaging)
  • at least one .mjs code-split chunk under staticwebassets/
  • build/{Id}.props (the manifest plumbing consumers need to pick up the assets)
• New pack-smoke job in .github/workflows/ci.yml runs dotnet pack exactly the way release does, then runs the verifier — so the next time a module ships an empty package, CI fails before merge.

Verification

Locally, with everything cleaned (rm -rf wwwroot obj bin):

• Cold pack of SimpleModule.Users: now 89 entries including staticwebassets/SimpleModule.Users.pages.js, all .mjs chunks, and build/SimpleModule.Users.props.
• Cold pack of SimpleModule.Settings: now 29 entries including staticwebassets/SimpleModule.Settings.pages.js, the smaller chunk set, and build/SimpleModule.Settings.props.
• Warm-cache repack: identical output, no duplicate Content items (verified the Exclude="@(Content)" guard works).
• Verifier passes for both packed modules; correctly fails when a module's .nupkg is missing (regression check).

Test plan

• CI's new pack-smoke job runs npm run build + dotnet pack + verifier and reports green.
• On the next release, inspect a published module .nupkg (e.g. SimpleModule.Users 0.0.34) and confirm it contains staticwebassets/SimpleModule.Users.pages.js, the .mjs chunks, and build/SimpleModule.Users.props.
• Reference the new package version from a fresh consumer app and verify /_content/SimpleModule.Users/SimpleModule.Users.pages.js returns 200 and the login page renders end-to-end.